HTTP is a stateless protocol, meaning that each request is independent from the previous or following request, i.e. no history of the interactions between the client and server, even during the same session, is maintained. However, typical business transactions are dependent upon past transactions, i.e. they require statefulness. Historically, maintaining statefulness has required that the server be able to identify the source of the request, i.e. the client, in order to determine what other requests that client has made.
One way to maintain statefulness is through the use of cookies. A cookie is a piece of data that the server stores on the client's hard drive. When a client and a server interact, i.e. when the client requests a first web resource from the server, the client browser searches the client's hard drive for a cookie that is associated with the server. If the browser finds an appropriate cookie, data associated with the cookie, such as a client session identifier, is sent to the server along with the request. This provides the server with the ability to maintain information, via a server-maintained lookup table or the like, about the particular client. If the particular cookie is not present, the server treats the client's request as a request from a new client, i.e. a client for whom no history has been maintained. The server may then “set” a cookie by writing an identifier or other piece of information to the client's hard drive. After the cookie is set, any new request made by the client will start a new exchange of cookie information.
As stated above, the server typically maintains a lookup table, in which the server maintains and updates the history of all web resource requests that involve a particular cookie. However, if the user erases the cookies on the client's hard drive, refuses to accept cookies, or accesses the server from a different client, the server cannot add new requests to the lookup table and statefulness will not be maintained.
The need for stateful interactions is not limited to client-server interactions. For example, load balancers act as network traffic directors, reducing net congestion by directing clients to available servers. However, when state logic is maintained on the web server, as is the case with the above-described lookup table, load balancers also need to be aware of specific users in order to direct subsequent requests to the same server. This is called “sticky” load balancing because the end user is “stuck” to a particular web server even through multiple requests.
The two most widely implemented approaches to sticky load balancing are cookie-based and IP-based. In cookie-based load balancing, the load balancer injects its own cookie into the request stream, such that when the user makes a request, the client sends a load balancer cookie along with the appropriate server cookie, if available. The load balancer then looks in a table to match the cookie to the target server. Upon making the connection to the target web server, the web server will read the request for a server-supplied cookie, and, if found, know the state or history of the client.
One complication with cookie-based load balancing is that the lifespan of the load balancer's cookie must be coordinated with the lifespan of the server's cookie. For example, if the load balancer invalidates its cookie on the client before the session between the client and the server is completed, the load balancer may send the client to a server that has no knowledge of the client or its state.
The second approach is IP-based stickiness, where the load balancer simply looks at the client's IP address and makes an entry in a hash table. Subsequent requests from the same IP address go the same target web server. Of course, the server still needs to set a cookie on the client's hard drive in order to maintain statefulness during the interaction. Some drawbacks to this approach are that all clients accessing through a given proxy server will share the same origin IP address, and thus be directed to the same web server. This can result in unbalanced loads. Also, typically a “rolling window” is used so that connections from IP addresses remain sticky for a rolling fifteen minute window. This window needs to be correlated to the cookie expiration time set by the server. Furthermore, if a client's IP address changes, for example, because the proxy server the client was connected to has changed, statefulness is lost.
Both existing approaches require the use of cookies. Consumers, however, have grown leery of cookies in general, and many end users disable the feature or delete them from their systems. In addition, many wireless network protocols do not enable cookies to be used. This has the substantial downside of limiting the growth of e-commerce and prohibiting other web content that requires state.